Game data offloading to a blockchain

ABSTRACT

An example operation may include one or more of initiating a session between one or more users, identifying an active game status associated with the one or more users during the session, creating a link to the active games status, storing the link in a blockchain, creating a message comprising the link to the active game status, and broadcasting the message to a plurality of potential users.

TECHNICAL FIELD

This application generally relates to the management of network gamingon a blockchain, and more particularly, to game data offloading to ablockchain.

BACKGROUND

A blockchain is a type of computing architecture that enables apeer-to-peer distributed (shared and replicated) database or ledger, notcontrolled by a single organization or entity, but many different ones.Spanning across a network of independent machines, the configurationpermits the nodes to reliably track and maintain the state ofinformation in a system. In doing so, blockchain enables thecost-efficient creation of business networks without requiring a centralpoint of control. This configuration operates in contrast to traditionaldatabase-oriented systems, where independent parties maintain their ownsystems of record and reconcile updates with one another in inefficientand sometimes complex inter-organizational processes, which requires theservices of an independent, trusted third-party administrator.

The complexity of a modern online multiplayer environment places anenormous demand on the underlying technology and infrastructure used tosupport the gaming functions. While a shift to a predictive physicsmodel has helped some of the physics-based calculations to the clientside, the current state of the gaming environment still requires a gameserver to act as an authoritative unit to create, manage, and validatein-game events and actions. Many of these events are inconsequentialafter a relatively short amount of time, for example, tire tracks leftbehind another player's vehicle in a car driving game type environment,however, such trivial game changes still require a great deal ofcomputing resources and low-latency infrastructure to maintain thosesmall details in synchronization between players to achieve an immersiveenvironment. When a game server becomes overloaded, the players'expectations are not always met, and the perception of quality suffersimmediately.

The timeline for online gaming is parallel to the timeline fordistributed computing. When dumb terminals were connected to mainframesand minicomputers, multiplayer games sent the gamer's controller inputsand waited for the response, which would then be rendered on the screenby the game engine. All in-game processing was handled server-side. Whenclient/server became popular, and some operations were performed on theuser's computer hardware, game consoles and the computers began handlingmore of the collision detection and graphical rendering for massivemultiplayer online role-playing (MMORPG) and first-person shooter (FPS)games. Today, a system of record and engagement modeling in computing isused where the responsibility for driving the user experience isoffloaded to the end device. Online gaming has taken a similar approachwith the predictive physics approach, where the client's hardware andsoftware predicts how the server will respond, and presents that to theuser immediately while it waits for the server confirmation. Thisprovides that a button-press is reflected in gameplay without delay,delivering a single-player reaction time with multi-player interactions.This is the current state-of-the-art, but gamers are a demandingincreased optimization for online games, and any new game that does notuse predictive physics would likely be criticized for having clunkyunresponsive controls.

SUMMARY

One example method of operation may include one or more of initiating asession between one or more users, identifying a current status of useractivities associated with the one or more users during the session,determining whether the current status of the user activities requiresupdates to a local blockchain or a session blockchain, and storing thecurrent status of the user activities in one or more of a localblockchain and a session blockchain.

Another example embodiment may include an apparatus that includes aprocessor configured to perform one or more of initiate a sessionbetween one or more users, identify a current status of user activitiesassociated with the one or more users during the session determinewhether the current status of the user activities requires updates to alocal blockchain or a session blockchain, and store the current statusof the user activities in one or more of a local blockchain and asession blockchain.

Another example embodiment may include a non-transitory computerreadable storage medium configured to store instructions that whenexecuted causes a processor to perform one or more of initiating asession between one or more users, identifying a current status of useractivities associated with the one or more users during the session,determining whether the current status of the user activities requiresupdates to a local blockchain or a session blockchain, and storing thecurrent status of the user activities in one or more of a localblockchain and a session blockchain.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates a logic diagram of a game process being managed viathe blockchain, according to example embodiments.

FIG. 1B illustrates a blockchain system configuration according toexample embodiments.

FIG. 2A illustrates a logic diagram of information flow and processesfor data offloading management via the blockchain, according to exampleembodiments.

FIG. 2B illustrates a logic diagram of examples used to determine whichblockchain to use to store game data and whether to broadcast or ignorethe game data, according to example embodiments.

FIG. 3 illustrates a system messaging diagram of the interactionsbetween game clients, a game server and the blockchain, according toexample embodiments.

FIG. 4A illustrates a flow diagram of an example method of managing gamedata offloading in the blockchain, according to example embodiments.

FIG. 4B illustrates a flow diagram of an example method of managing gamedata access in the blockchain, according to example embodiments.

FIG. 5 illustrates an example network entity configured to support oneor more of the example embodiments.

DETAILED DESCRIPTION

It will be readily understood that the instant components, as generallydescribed and illustrated in the figures herein, may be arranged anddesigned in a wide variety of different configurations. Thus, thefollowing detailed description of the embodiments of at least one of amethod, apparatus, non-transitory computer readable medium and system,as represented in the attached figures, is not intended to limit thescope of the application as claimed, but is merely representative ofselected embodiments.

The instant features, structures, or characteristics as describedthroughout this specification may be combined in any suitable manner inone or more embodiments. For example, the usage of the phrases “exampleembodiments”, “some embodiments”, or other similar language, throughoutthis specification refers to the fact that a particular feature,structure, or characteristic described in connection with the embodimentmay be included in at least one embodiment. Thus, appearances of thephrases “example embodiments”, “in some embodiments”, “in otherembodiments”, or other similar language, throughout this specificationdo not necessarily all refer to the same group of embodiments, and thedescribed features, structures, or characteristics may be combined inany suitable manner in one or more embodiments.

In addition, while the term “message” may have been used in thedescription of embodiments, the application may be applied to many typesof network data, such as, packet, frame, datagram, etc. The term“message” also includes packet, frame, datagram, and any equivalentsthereof. Furthermore, while certain types of messages and signaling maybe depicted in exemplary embodiments they are not limited to a certaintype of message, and the application is not limited to a certain type ofsignaling.

The instant application in one embodiment relates to the management ofnetwork gaming on a blockchain, and in another embodiment relates tomanaging offloading of gaming data onto one or more blockchains tooptimize user gaming experiences.

Example embodiments provide offloading some of the in-game processing ofan online game to a shared ledger (i.e., blockchain). Examples mayinclude offloading inconsequential data to collective ledgers on theclient side, such as a local blockchain or other less used datamanagement entity. By storing such activity data, the transactional datacan be linked to any purchases and/or real or cryptocurrencytransactions. Also, the online activity data may be offloaded from acentralized activity server to the customized temporary ledgers. Theactivity may be any collaboration between users including groupprojects, group papers, group conferences, multi-user games, etc. In thegaming example, viewing the gameplay transactional data to analyze therisk and cost associated with specific transactions may be performed toevaluate data analytics. If a transaction is classified as a high-riskscenario, meaning the end user has invested some type of real currency,then the gameplay data will be analyzed to make sure that that the gameevents and related transactions are correct and match what was recordedon the blockchain.

Limits and ratios may be set to determine where resources will be spentto validate the game data. The players of the multi-user game may beresponsible for performing a majority of the object and transactionchecking, while the servers will check by generating message to theplayers periodically to confirm that everything appears valid. Thisapproach may reduce server data load and permit for the work to besynchronized across all the players. In the current multi-user, online,network or related gaming environment most online game engines do notkeep track of every object and every transaction since the servers wouldnot be able to support this much data interaction. By introducingblockchains, the inconsequential data will be offloaded to collectiveledgers on the client side. This will safeguard transactional data,which may be tied back to real currency, while offloading the gamesession data from the gaming servers to temporary ledgers. This modelwill view the gameplay transactional data to analyze the risks and costsassociated with specific transactions. If the transaction is classifiedas a high-risk scenario, such as when the end user has invested sometype of real currency, then the gameplay data will be analyzed to ensurethat everything is correct and matches what was recorded on theblockchain.

According to example embodiments, fully-interactive gaming environmentsmay include, for example, fluid interactions with simulated characters,such as roads that turn slick and reflective when it rains, and theability to influence in-game events is expected to occur simultaneouslyfor everyone logged into the same game session. In order to maintain thelevel of detail and the type of experience that is expected by theplayer while optimizing performance and the immersion of the simulation,there needs to be a change in the way developers approach the way gamersinteract with the game model.

One approach is the offloading of some of the in-game processing to ashared ledger (i.e., blockchain). There are certain functions that agame console or user computer can perform well, however, in an onlinegaming environment, all of those actions should be synchronized acrossall players at some point, and a blockchain configuration provides amedium as a collective ledger, based on a set of pre-defined rules,which can optimize an online multiplayer game. The actions in a typicalonline game can be identified as one or two main categories includinginteractions between users and a game model and actions of one userwhich need to be made visible to other users. For example, when a player‘1’ moves their character down a path, then player ‘2’ should not onlybe able to view this animation of player ‘1’ moving on their screen, butmust also be able to interact with that player. For this reason,information, such as the map/screen position and action (i.e., walking,running, driving, etc.) of a player and actions (i.e., moving, using atool, engaging other players) they are performing needs to be rapidlyrelayed to other players. However, one player sitting in a car in themiddle of a field honking their car horn is not relevant to the otherplayers since it does not effect their game status on the other side ofthe map.

According to example embodiments, to reduce the number of messages thatneed to be broadcast and received, each player only receives informationthat is relevant to them. This is typically performed based on anin-game location and what is visible/audible to other players. Suchinformation is enough information to create a basic multiplayer userenvironment. Procedurally-generated actions based on initial seedvalues. Since most online games are more involved than two players on afeatureless flat plane, then to create the illusion of a single “world”being experienced simultaneously by multiple players, most game enginesrely on the ‘gamestate’. The gamestate is a true moment-in-timerepresentation of everything that affects another player's gameexperience in that world/environment. In a modern online multiplayergame, it would be burdensome to track every single object andnon-playable characters (NPC), and most online game engines do notprovide such services. Rather, they start with a series of seededvalues. Those values will affect the output of pseudo-random-numbergenerators, which will in turn create the illusion of a unique universeeach time. For example, when a multiplayer game session begins, it willneed to determine where to create (spawn) all of the backgroundcharacters, or non-playable characters (NPCs). The session will useanother value to determine the clothes that player should be wearing,another to determine the body type, and another to determine theiraction. If that action is “walking”, another value will be used todetermine where the player's avatar is going.

In a single player experience, certain values may be randomly generatedto arrive at a 100% unique game experience every time the game isinitiated. To ensure that multiple users can experience the sameseemingly-random universe/area/environment, each player begins theirsession with the same set of “seed” values. Like a stacked deck ofcards, the randomness is only so random. Even when a player seeminglydisrupts the environment, by parking a vehicle in the middle of acrowded intersection, NPCs will still react the same in player ‘1's’universe as they do in player ‘2's’.

According to one example, in-game transactions and data changes, such asaccumulating coins, money, points and certain items, such asmodifications, weapons, bonus elements, etc. This information may berecorded and reflected in the game model, as it could affect all futuregameplay. This includes gains and losses of in-game money, ownership ofobjects, completion of tasks, and in-game character appearance. This canbe thought of as being analogous to the many ways one can talk about abaseball game. The time of day, location, starting lineup, and playersavailable are the seed values that are used to build the gameenvironment. The hits, runs, errors, and strikes are in-game events thatare high-level and will be recorded to update the player statisticsgoing forward. Details about how close a play was at home base, and thespeed of a fastball might be interesting at the moment, but ultimatelydo not play into who wins the Championship.

A blockchain-based model permits the offloading of a significant portionof a game's processing to the collective client side. This is somethingthat is not possible before blockchain became a viable technology. Thereare two main classifications of messages handled in a typicalmultiplayer online gaming environment. Type ‘1’ data is broadcastthrough a simple messaging platform, which could be a messagingplatform, which is useful for keeping track of the movements of otherplayers with low latency. Simple filtering and models may limit the useof bandwidth and system resources. Type ‘2’ data, the information whichrecords deviations from the initial gamestate, needs to be madeavailable so that players can work off the same set of records. Forexample, simply knowing that player #1 is standing in one location, andplayer #2 walking into that area also needs to know that they broke allthe wooden crates in the area, so both players are observing the sameenvironment, and that player #2 is not going to break the same crates.

To facilitate the game environment in a serverless model, multipleblockchains may be used with rapid block read, write and update times sothat a player entering an area being affected by another player can bequickly brought up to date with all changes that might affect theirexperience. As this data is used solely to synchronize user experiencesin the same area, the blockchains are not participated in by the gameserver unless cheating is suspected, in which case, actions leading upto and including the cheating can be viewed by “playing back” theactions.

For persisted data, a second type of blockchain may be used, whichpersists for the length of the private gaming session. Tracking thosechanges should be treated just as one would track real-world monetarytransactions, as in-game items and currency are often purchased items,and it is required that they are not be forged by players seeking toexploit the game's economy. Blockchains are not a suitable solution whenhigh-speed, low-latency communication is required. In the case of aplayer-vs-player (PvP) or Co-Operative (co-op) situation, the outcome ofan encounter between different players is often decided on who wasfaster by hundredths of a second. To facilitate those situations, a moretraditional messaging system can be used, which can be a messagingplatform or any other platform for low-latency messaging between peers.This data needs to be dispersed as quickly as possible, and does notneed to be persisted once read. An example of this distinction mayinclude two players driving in two different vehicles down a streetwhile other players watch. For the players not directly involved, it isadequate for them to receive updated information on the vehicle'smovement and position every 500 ms. This is sufficient data to keep theenvironment consistent between participants without requiring a massiveamount of network resources. If those two players were racinghead-to-head, however, that level of detail resolution would probablynot be sufficient, which is where a highspeed messaging platform wouldbecome a requirement.

To validate the transactions, every event in the game is assigned aunique ID so that it can be easily identified by other players, orduring a verification effort afterwards. The identifier, along with thevalues and identifier of the event, will be used as a *salt*, along withcryptographic keys to create a message authentication code. With thisinformation, any other player can validate that any event seeking to berecorded by any player was generated based on the original seededvalues. This can be verified by other players in the session, as theyhave to be logged out via the type ‘1’ broadcast system, and because thevalues cannot be tampered with without producing an invalid MAC. Withthis framework, it is possible to increase complexity and richness ofthe simulated environment, while keeping the server-side processinglargely decoupled from moment-to-moment gameplay.

With appends made to local and game session blockchain, the informationis immediately visible to all players who may be affected and need toupdate their environment model through gameplay or user to user chatsessions, which occurs over the high-speed messaging platform. A newblock can be confirmed based on a timer, a message threshold, or anotherparameter based on the specific implementation.

FIG. 1A illustrates a logic diagram of a game process being managed viathe blockchain, according to example embodiments. Referring to FIG. 1A,the example configuration 100 includes a game server 120 responsible forhosting one or more games managed by a game process 110, which storesand utilizes game records 112 and user records 114. The users 102, 104 .. . 106 may be part of an ongoing game session managed by the gameserver 120. The two blockchains are used to store information aboutevents which took placed during the game operation.

In order to offload data managed by the game server 120, the differenttypes of in-game messaging and transactions may be offloaded to channelsbetter suited for online multiplayer environments. Once example of ascenario using all three channels including direct (chat), localblockchain, and session blockchain would be for a racing simulation.Blockchain, is not the ideal selection for situations that require lowlatency. For instance, person-to-person or server/client communicationis needed to keep players synchronized of where other car racers arearound them on the race track. During the race, a racer may knock into alamppost or leave skidmarks on a turn. That information needs to persistfor racers coming into that area behind them, so it is kept in the localblockchain 130, possibly until it is deemed no longer relevant, orhasn't been accessed in X seconds/minutes. Lastly, any sort of laprecords or top speeds or high scores or achievement unlocks that happenwould take place on the session blockchain 140, mostly so that they canbe validated by the game server and/or other gaming participants.

The chat or messaging platform is used when low latency is required, andis used not just for chat, but the immediate coordinates of otherplayers, vehicles, projectiles, low bandwidth data sharing, etc. Inother examples, more and more in-game items and in-game currency can betied to real-world currency. For example, an increasingly common gamemodel is to sell a game, and then sell in-game currency afterwards.Players have the option of earning that money by completing missions,which can be time consuming, and which may be referred to as ‘grinding’,or, alternatively, they can buy in-game currency. If in-game currency ischeated or hacked, then players won't spend real-world money on in-gamecurrency, and development can't continue. A single hack that permitsusers to sell the same car multiple times, results in a real-world lossof revenue by the publisher due to loss of player trust and interest. InFIG. 1A, the local transaction blockchain 130 is storing a lessimportant game event, which is stored by an object ID 132, and objectdetails, such as its location and status 134. The changes are identifiedas they occur and logged in the blockchains depending on their eventtype. In the example of the game session blockchain 140, the transactionis a purchase with an event ID 142 and event details 144 and a MACaddress 146 to verify the purchase or sale of an in-game item.

In another game example, events may include driving and hitting alamppost, breaking a crate, moving an elevator between floors, turning alight switch on/off, destroying the wall of a building, creatingtire/skid marks. Any of those examples may be identified and categorizedby an event type so the correct blockchain can be used to log theevent(s), in this case, the local transaction blockchain 130. In anotherexample, events which may be identified and stored in the sessionblockchain may include trading items with other users, leaderboard-basedawards, such as setting a new record in a race or other competition,finding/unlocking new items, obtaining in-game items that everyone elsecan obtain, anything that has consequences outside of the current gamesession, character augmentation/enhancements, such as spending in-gamecurrency to enhance a character. Buying a new item in-game should be asession transaction because if it is not, then it may be possible forsomeone to sell the same vehicle repeatedly, collecting in-game currencyfaster than the publishers intended. Putting it on the sessionblockchain 140 allows for checking those actions against the seededvalues.

In most open-world games, a lot of the world seems completely arbitrary.For example, driving through a busy part of town will show hundreds ofpedestrians and drivers in vehicles moving through the area. This iseasy enough to setup in a single-player game, but becomes morechallenging when trying to synchronize that experience for multipleplayers. Two players in the same session need to be able to say “Let'smeet over there by the blue car in front of the store” and see the samething otherwise the multi-player experience falls apart. The way this ispossible in games is by starting the game session with a set of seededvalues. This can be a single long value, or a series of values, but theapproach is to start with a certain amount of entropy. With all playerssharing these values, any “random” number that is generated using thesame algorithm and the same seed values will yield the same resultsbetween players. This is how car colors, traffic light timings,pedestrian patterns, and in-game weather can produce a seeminglyinfinite number of combinations, but stay synchronized across sessions.This is similar to having four decks of cards that have been shuffled inexactly the same way.

FIG. 1B illustrates a blockchain system configuration according toexample embodiments. The blockchain system 150 may include certaincommon blockchain elements, such as a group 180 of assigned peers182-185 which participate in the blockchain transaction addition andvalidation process (consensus). Any of the blockchain peer nodes 180 mayinitiate new transactions and seek to write to the blockchain immutableledger 172, a copy of which is stored on the underpinning physicalinfrastructure 171. In this configuration, the customized blockchainconfiguration may include one or applications 177 which are linked toAPIs 176 to access and execute stored program/application code (e.g.,chain code and/or smart contracts) 175, which are created according tothe customized configuration sought by the participants and can maintaintheir own state, control its own assets, and receive externalinformation. This code can be deployed as a transaction and installed,via appending to the distributed ledger, on all blockchain peer nodes.

The blockchain base 170 includes the various layers of blockchain data,services (e.g., cryptographic trust services, virtual executionenvironment), and underpinning physical computer infrastructurenecessary to receive and store new transactions and provide access toauditors which are seeking to access data entries. The blockchain layer172 exposes an interface that provides access to the virtual executionenvironment necessary to process the program code and engage thephysical platform 171. Cryptographic trust services 173 are used toverify transactions and keep information private. As a result, smartcontract changes which are proposed and/or approved (i.e., via consensusamong peers) can be created and updated on the blockchain to accuratelyupdate consumer debt information.

The blockchain configuration of FIG. 1B may process and executeprogram/application code 175 by way of the interfaces exposed, and theservices provided, by blockchain platform 170. The code may controlblockchain assets, for example, it can store and transfer data, and maybe executed by the blockchain in the form of a smart contract, whichincludes chain code with conditions or other code elements subject toits execution. The smart contracts 175 may be created to executereminders, updates, and/or other notifications subject to the changes,updates, etc. The smart contracts can themselves be used to identifynetwork usage and data IO statuses and compare the actual networkresource levels to contractual thresholds and other variables which maybe exceeded or enacted to launch changes or notifications. For example,the thresholds of data IO, if exceeding smart contract levels, may beidentified and used as the basis for a tier change, notification and/orsuggested course of action, both manual and/or automated. The tieringmay occur automatically if the smart contract permits the change upondetection of the exceeded threshold. The game policies 169, once decidedby the peers via consensus, can be updated into the smart contracts 175accordingly.

In this example embodiment, the smart contract may store requirements ofone or more users/consumers to the network. The requirements may be anytype of network resources, such as memory, CPU utilization, throughput,bandwidth, priority, etc. The requirements may be itemized in a networkresource usage policy table or file. The policies related to therequirements may define the requirements and the provider requirementsnecessary to fulfill the consumer needs. The smart contract may storesuch information and may be referenced by providers seeking to conducttransactions with those consumers, especially when the provider has theresources to provide. The results of a consumption session may be storedin the blockchain as an updated log to the smart contract execution.Event types 168 may be identified as belonging to one or more sub-chainsof the blockchain 172. For example, game events 168 which are global orimportant to all players may be stored in the session wide blockchainwhile other game events which are less important may be stored in thelocal blockchain.

FIG. 2A illustrates a logic diagram of information flow and processesfor data offloading management via the blockchain, according to exampleembodiments. Referring to FIG. 2A, this example is a workflow diagram200 for creation and usage of the blockchains. The left server-side ofthe diagram includes a new session being initiated 202 and session seedsbeing generated and stored 204 in the session wide ledger 222. Thisincludes game session data 210 and provides for generating 212 the newblockchain ledger 222 for the new game session. A private game sessionmessaging system 226 instance may be generated 214 to permit datamessaging as an alternative to using the blockchains. The in-game eventsare identified and recorded 216 in a player environment data repository218.

The client-side example provides a player entering a session 232 andobtaining core information the game server 234. The environment is builtfrom the session wide ledger 236. The code accessing the session-wideledger determines if there is a local ledger created yet 238. Forexample, if a player in a new session enters an area of the map wherenobody else has been yet, it can be assumed that there is no localledger created for that area, for example purposes, that new area willbe referred to as ‘1,1’. The session blockchain is checked for this, andspawns a local ledger, noting its creation and connection informationinto the session blockchain. Now, when player #2 enters area ‘1,1’, theyknow where to access the current local blockchain 224. This is acrossover between the two types of blockchains. Any style of blockchainmay be used since one can assume that the local blockchains will havefaster refresh windows, and perhaps a higher tolerance for disagreementbetween participants, whereas the session blockchains afford for morestringent checking, since in-game currency is being used. The localledger is created 242 if it does not exist, otherwise it is read from244 when recording environment modifications and other actions 246. Thatenvironment is updated according to updates from others 248.

In a specific game example according to example embodiments, fourplayers may accept a quest to find a dragon. The mission includes havingthe player avatars (characters) walk through a dungeon full of traps andat the end is a dragon guarding a one of a kind treasure chest. Theplayers have weapons and magic spells that can attack enemies whiletraversing through the dungeon. On their way, they occasionally fightmonsters who drop loot that the players collect. The actions of walkingaround, using an attack, and using any chat functions will be placedinto the “real time communications channel”. These are actions based onthe immediate actions of the player and directly around the player. Thistype of information is not important to the game session and only forthe immediate reference for the players. While walking around the gamelandscape, the players run into holes and traps that they must escapefrom. Those occurrences are on the local blockchain since it is onlypertinent to the current session. Players participating in this currentsession need to know about these occurrences but only within thisoccurrence. Outside of this environment, a different player does notneed to know about the traps or holes. For example, if player 1 runsahead of the others and breaks apart a treasure crate, that informationwill need to be persisted when players 2, 3 and 4 catch up with them, sothat information will be placed on the local blockchain.

The players finally enter the dragon's den in which the dragon has 1000health points. Each successful attack on the dragon lowers that value.After attacking and casting spells, the dragon's health points diminishto 0 and the dragon disappears. They then approach the rare treasurechest and obtain the treasure. The dragon and the treasure chest cannever be re-obtained by the players, nor can they re-obtain the itemsthat they collected from the dragon and chest. Due to the importantinformation about defeating the dragon and obtain these items, thiswould be recorded on the session blockchain so that the information canbe validated every time the player enters a game session.

FIG. 2B illustrates a logic diagram of examples used to determine whichblockchain to use to store game data and whether to broadcast or ignorethe game data, according to example embodiments. Referring to FIG. 2B,the example 250 includes one or more in-game events being identifiedduring a gaming session 252. For example, a player may jump, unlock adoor, knock over a lamppost, buy a car, defeat an enemy, cause anon-playable character to become angry, make skid marks, and complete amission. Among those player events, a determination can then be made asto whether the other players require an immediate update 254, if so, areal time communication channel 264 may be used to update those playersvia broadcast. The relevant players are identified and updated via thebroadcast option. If the immediate update is not required, adetermination is made to determine whether the action will permanentlyaffect the user's character, game or otherwise by a permanent changethat should be persisted 256. If so, the choice is to log the event inthe session blockchain 266. The changes may include changing levels in agame, spending money, changing appearance, completing a mission, etc.The changes should be verified and recorded for future gameplay. If thechanges are not permanent but temporary and should still be recorded258, the local blockchain 268 should be used to store the events thatwill be necessary for consistency among players, such as knocking over amailbox, tire tracks, or something that alters a pre-seeded flow. Allplayers nearby will need to observe those changes for consistency. Thosechanges are not long term. If however, the changes are not important anddo not impact others, the game changes may not be persisted 270 in anyblockchain and will otherwise be ignored or disregarded.

FIG. 3 illustrates a system messaging diagram 300 of the interactionsbetween game clients, a game server and the blockchain, according toexample embodiments. Referring to FIG. 3, the system 300 may include anumber of components or modules which may include software, hardware orthe combination of both. The components may include a first component,such as one or more game players or clients 310 which may enter a gamesession 312 and access a second component, such as game server 320. Thecore game information may be updated 314 based on data of a session wideledger 315 stored on a third component, such as a blockchain 330. Theenvironment may be built 316 and rendered for the user device. The gamedata is shared with the user device 318 and new events are identifiedand sent to the server 322 based on user actions. The event type 324 maybe determined to be a local or session wide event 325. The session wideledger 350 may be updated accordingly or the local ledger 360 dependingon the type of event which occurred. Also, as an alternative, themessaging needed 326 may be determined instead to create a messagingscenario to create messages 328. The notifications may be forwarded 332to the clients as needed depending on the events.

In one embodiment, the first component, the second component and thethird component may be separate devices such as servers, computers orother computational devices or may be a single device. In otherembodiments, the first component and the second component may beenclosed as, or perform as, a single device, the first component and thethird component may be enclosed as, or perform as, a single device, andthe second component and the third component may be enclosed as, orperform as, a single device. The components or devices 310, 320 and 330may be directly connected or communicably coupled to one another, in awired or wireless manner, and may reside locally and/or remotely.

FIG. 4A illustrates a flow diagram of an example method of managing gamedata offloading in the blockchain, according to example embodiments.Referring to FIG. 4A, the method 400 may include initiating a sessionbetween one or more users 412, identifying a current status of useractivities associated with the one or more users during the session 414,determining whether the current status of the user activities requiresupdates to a local blockchain or a session blockchain 416, and storingthe current status of the user activities in one or more of a localblockchain and a session blockchain 418. The session includes one ormore of a chat session, an application sharing session and amulti-player gaming session.

The method may also include determining whether the local blockchainexists for the current status of the user activities, if not, creatingthe local blockchain, and storing the current status of the useractivities and an environment associated with the current user status inthe local blockchain. The method may also include determining whetherthe local blockchain exists for the current status of the useractivities, if so, retrieving transaction data from the local blockchainand modifying an environment associated with the current user status,and storing the current status of the user activities and the modifiedenvironment in the local blockchain. The method may further includedetermining the current status of the user activities requires updatesto the session blockchain based on an event type associated with thecurrent user activities, and storing the current status of the useractivities in the session blockchain. Also, the method may includeidentifying the current status of the user activities includes aninstance of private messaging. The method may further include creating aprivate messaging session, and storing the current status of the useractivities in the private message session.

FIG. 4B illustrates a flow diagram of an example method of managing gamedata access in the blockchain, according to example embodiments.Referring to FIG. 4B, the method 450 may include initiating a sessionbetween one or more users 452, identifying an active game statusassociated with the one or more users during the session 454, creating alink to the active games status 456, storing the link a blockchain 458,and creating a message comprising the link to the active game status,and broadcasting the message to a plurality of potential users 462. Inthis example, the active games session is identified by a link which canbe easily shared with others so access to the game can be readilyobtained by other parties. The link is stored in a public ledger foraccess and a message may be made and shared to notify the others of thegame session and to create private invites to those who are available tojoin the session.

Example embodiments may be a system, a method, and/or a computer programproduct at any possible technical detail level of integration. Thecomputer program product may include a non-transitory computer readablestorage medium (or media) having computer readable program instructionsthereon for causing a processor to carry out aspects of the embodiments.

The non-transitory computer readable storage medium can be a tangibledevice that can retain and store instructions for use by an instructionexecution device. The computer readable storage medium may be, forexample, but is not limited to, an electronic storage device, a magneticstorage device, an optical storage device, an electromagnetic storagedevice, a semiconductor storage device, or any suitable combination ofthe foregoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the embodiments.

Aspects of the embodiments are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products. It will be understood thateach block of the flowchart illustrations and/or block diagrams, andcombinations of blocks in the flowchart illustrations and/or blockdiagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

An exemplary storage medium may be coupled to the processor such thatthe processor may read information from, and write information to, thestorage medium. In the alternative, the storage medium may be integralto the processor. The processor and the storage medium may reside in anapplication specific integrated circuit (“ASIC”). In the alternative,the processor and the storage medium may reside as discrete components.For example, FIG. 5 illustrates an example network element 500, whichmay represent or be integrated in any of the above-described components,etc.

As illustrated in FIG. 5, a memory 510 and a processor 520 may bediscrete components of a network entity 500 that are used to execute anapplication or set of operations as described herein. The applicationmay be coded in software in a computer language understood by theprocessor 520, and stored in a computer readable medium, such as, amemory 510. The computer readable medium may be a non-transitorycomputer readable medium that includes tangible hardware components,such as memory, that can store software. Furthermore, a software module530 may be another discrete entity that is part of the network entity500, and which contains software instructions that may be executed bythe processor 520 to effectuate one or more of the functions describedherein. In addition to the above noted components of the network entity500, the network entity 500 may also have a transmitter and receiverpair configured to receive and transmit communication signals (notshown).

Although an exemplary embodiment of at least one of a system, method,and non-transitory computer readable medium has been illustrated in theaccompanied drawings and described in the foregoing detaileddescription, it will be understood that the application is not limitedto the embodiments disclosed, but is capable of numerous rearrangements,modifications, and substitutions as set forth and defined by thefollowing claims. For example, the capabilities of the system of thevarious figures can be performed by one or more of the modules orcomponents described herein or in a distributed architecture and mayinclude a transmitter, receiver or pair of both. For example, all orpart of the functionality performed by the individual modules, may beperformed by one or more of these modules. Further, the functionalitydescribed herein may be performed at various times and in relation tovarious events, internal or external to the modules or components. Also,the information sent between various modules can be sent between themodules via at least one of: a data network, the Internet, a voicenetwork, an Internet Protocol network, a wireless device, a wired deviceand/or via plurality of protocols. Also, the messages sent or receivedby any of the modules may be sent or received directly and/or via one ormore of the other modules.

One skilled in the art will appreciate that a “system” could be embodiedas a personal computer, a server, a console, a personal digitalassistant (PDA), a cell phone, a tablet computing device, a smartphoneor any other suitable computing device, or combination of devices.Presenting the above-described functions as being performed by a“system” is not intended to limit the scope of the present applicationin any way, but is intended to provide one example of many embodiments.Indeed, methods, systems and apparatuses disclosed herein may beimplemented in localized and distributed forms consistent with computingtechnology.

It should be noted that some of the system features described in thisspecification have been presented as modules, in order to moreparticularly emphasize their implementation independence. For example, amodule may be implemented as a hardware circuit comprising custom verylarge scale integration (VLSI) circuits or gate arrays, off-the-shelfsemiconductors such as logic chips, transistors, or other discretecomponents. A module may also be implemented in programmable hardwaredevices such as field programmable gate arrays, programmable arraylogic, programmable logic devices, graphics processing units, or thelike.

A module may also be at least partially implemented in software forexecution by various types of processors. An identified unit ofexecutable code may, for instance, comprise one or more physical orlogical blocks of computer instructions that may, for instance, beorganized as an object, procedure, or function. Nevertheless, theexecutables of an identified module need not be physically locatedtogether, but may comprise disparate instructions stored in differentlocations which, when joined logically together, comprise the module andachieve the stated purpose for the module. Further, modules may bestored on a computer-readable medium, which may be, for instance, a harddisk drive, flash device, random access memory (RAM), tape, or any othersuch medium used to store data.

Indeed, a module of executable code could be a single instruction, ormany instructions, and may even be distributed over several differentcode segments, among different programs, and across several memorydevices. Similarly, operational data may be identified and illustratedherein within modules, and may be embodied in any suitable form andorganized within any suitable type of data structure. The operationaldata may be collected as a single data set, or may be distributed overdifferent locations including over different storage devices, and mayexist, at least partially, merely as electronic signals on a system ornetwork.

It will be readily understood that the components of the application, asgenerally described and illustrated in the figures herein, may bearranged and designed in a wide variety of different configurations.Thus, the detailed description of the embodiments is not intended tolimit the scope of the application as claimed, but is merelyrepresentative of selected embodiments of the application.

One having ordinary skill in the art will readily understand that theabove may be practiced with steps in a different order, and/or withhardware elements in configurations that are different than those whichare disclosed. Therefore, although the application has been describedbased upon these preferred embodiments, it would be apparent to those ofskill in the art that certain modifications, variations, and alternativeconstructions would be apparent.

While preferred embodiments of the present application have beendescribed, it is to be understood that the embodiments described areillustrative only and the scope of the application is to be definedsolely by the appended claims when considered with a full range ofequivalents and modifications (e.g., protocols, hardware devices,software platforms etc.) thereto.

What is claimed is:
 1. A method, comprising: communicating, during anonline game session, an update of a current status of a first useractivity associated with at least one of a first user and a second userin the online game session to a local blockchain; communicating, duringan online game session, an update of a current status of a second useractivity associated with at least one of the first user and the seconduser in the online game session to a session blockchain; and validatingthe update to the session blockchain in response to the first user orthe second user entering a new game session.
 2. The method of claim 1,wherein the game session comprises one or more of: a chat session and anapplication sharing session.
 3. The method of claim 1, furthercomprising: determining whether the local blockchain exists for thecurrent status of the user activity; if not, creating the localblockchain; and storing the current status of the user activity and anenvironment associated with the current status in the local blockchain.4. The method of claim 1, further comprising: determining whether thelocal blockchain exists for the current status of the user activity; ifso, retrieving transaction data from the local blockchain and modifyingan environment associated with the current status; and storing thecurrent status of the user activity and the modified environment in thelocal blockchain.
 5. The method of claim 1, further comprising:determining the current status of the user activity requires updates tothe session blockchain based on an event type associated with thecurrent user activity; and storing the current status of the useractivity in the session blockchain.
 6. The method of claim 1, furthercomprising: identifying that the current status of the user activitycomprises an instance of private messaging.
 7. The method of claim 6,further comprising: creating a private messaging session; and storingthe current status of the user activity in the private message session.8. An apparatus, comprising: a memory storing one or more instructions;and a processor that executes the one or more instructions to configurethe processor to: communicate, during an online game session, an updateof a current status of a first user activity associated with at leastone of a first user and a second user in the online game session to alocal blockchain; communicate, during an online game session, an updateof a current status of a second user activity associated with at leastone of the first user and the second user in the online game session toa session blockchain; and validate the update to the session blockchainin response to the first user or the second user entering a new gamesession.
 9. The apparatus of claim 8, wherein the game session comprisesone or more of: a chat session and an application sharing session. 10.The apparatus of claim 8, wherein the processor is further configuredto: determine whether the local blockchain exists for the current statusof the user activity; if not, create the local blockchain; and store thecurrent status of the user activity activities and an environmentassociated with the current user status in the local blockchain.
 11. Theapparatus of claim 8, wherein the processor is further configured to:determine whether the local blockchain exists for the current status ofthe user activity; if so, retrieve transaction data from the localblockchain and modify an environment associated with the current status;and store the current status of the user activity and the modifiedenvironment in the local blockchain.
 12. The apparatus of claim 8,wherein the processor is further configured to: determine the currentstatus of the user activity requires updates to the session blockchainbased on an event type associated with the current user activity; andstore the current status of the user activity in the session blockchain.13. The apparatus of claim 8, wherein the processor is furtherconfigured to: identify that the current status of the user activitycomprises an instance of private messaging.
 14. The apparatus of claim13, wherein the processor is further configured to: create a privatemessaging session; and store the current status of the user activity inthe private message session.
 15. A non-transitory computer readablestorage medium storing one or more instructions that when executed by aprocessor causes the processor to perform: communicating, during anonline game session, an update of a current status of a first useractivity associated with at least one of a first user and a second userin the online game session to a local blockchain; communicating, duringan online game session, an update of a current status of a second useractivity associated with at least one of the first user and the seconduser in the online game session to a session blockchain; and validatingthe update to the session blockchain in response to the first user orthe second user entering a new game session.
 16. The non-transitorycomputer readable storage medium of claim 15, wherein the game sessioncomprises one or more of: a chat session and an application sharingsession.
 17. The non-transitory computer readable storage medium ofclaim 15, wherein the one or more instructions further cause theprocessor to perform: determining whether the local blockchain existsfor the current status of the user activity; if not, creating the localblockchain; and storing the current status of the user activity and anenvironment associated with the current status in the local blockchain.18. The non-transitory computer readable storage medium of claim 15,wherein the one or more instructions further cause the processor toperform: determining whether the local blockchain exists for the currentstatus of the user activity; if so, retrieving transaction data from thelocal blockchain and modifying an environment associated with thecurrent status; and storing the current status of the user activity andthe modified environment in the local blockchain.
 19. The non-transitorycomputer readable storage medium of claim 15, wherein the one or moreinstructions further cause the processor to perform: determining thecurrent status of the user activity requires updates to the sessionblockchain based on an event type associated with the current useractivity; and storing the current status of the user activity in thesession blockchain.
 20. The non-transitory computer readable storagemedium of claim 15, wherein the one or more instructions further causethe processor to perform: identifying the current status of the useractivity comprises an instance of private messaging; creating a privatemessaging session; and storing the current status of the user activityin the private message session.